]> Massachusetts Institute of Technology

hartmans-ietf@mit.edu

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 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.

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 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 user name and password. The security of passwords over TLS depends on making sure that the password is sent to the right, trusted server. HTTPs implementations typically confirm that the name entered by the user in the URL corresponds to the certificate. 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. 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. 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. 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 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 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.

In publishing this memo, the IETF recommends the development of web authentication mechanisms that meet the requirements outlined in . It is hoped that developing 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.

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.

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 .

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. 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. 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.

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. 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. It's not clear how valuable this limitation on the attacker's ability will prove in practice. Research into the effectiveness of security indicators 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. 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.

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. Note that some authentication systems such as Kerberos 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. Of less serious concerns at the present time are attacks on data integrity where a phisher provides false or misleading information to a user.

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" . Most of this work was discovered independently but work from that paper has been integrated where appropriate. It is desirable that these requirements are similar to the principles outlined by someone facing phishing as an operational reality.

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. 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. 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.

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. There are three basic approaches to establishing a trusted UI. The first is to use a dynamic UI based on a secret shared by the user and the local UI; the paper 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. See for another case where confidential information in a UI can be used to build trust.

A critical requirement is that when a user authenticates to a website, the website MUST NOT receive a strong password equivalent . A strong password equivalent is anything that would allow a phisher to authenticate as a user with a different identity provider. Weak password equivalents (quantities that act as a password for a given service but cannot be reused with other services ) MAY only be sent when a new identity is being enrolled or a password is changed. A weak password equivalent allows a party to authenticate to a given identity provider as the user. 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 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 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.

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. 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 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. For public key protocols, this requirement would mean that the server typically needs to sign an assertion of what identity it authenticated.

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. The authentication system MUST guarantee to the user and the target server that the response is generated by the target server and the contents of the response will only be seen by parties authorized by either the target server or the user. This can be done in several ways: 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. 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 section 2.2.2 of . Work is ongoing to adapt this concept to HTTP over TLS Redirect based schemes in which the identity provider is told what site to return the user to meets this requirement provided again that certificate validation is done at the TLS layer.

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. 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: The target server can provide a certificate issued by the identity provider as part of the authentication. 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.

One area of particular vulnerability to phishing is enrollment of a new identity in an identity provider. 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 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) 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.

In , 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. 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 , attackers can spoof the name in the URI. However the TLS checks do defeat some attacks. Also, as discussed in , TLS validation may be important to higher-level checks. 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. 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. In , 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 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 secret is displayed after authentication then phishers could not obtain the secret. This is one of the many reasons why it is important to prevent phishing targeted at authentication credentials.

This document requests no action of IANA.

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. I'd like to thank Eric Rescorla and Ben Laurie for their significant comments on this draft. Eliot Lear provided many last call comments and helped work through several long standing issues with the document. Christian Vogt provided text and review comments.

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 , 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; 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 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. 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.

&rfc2119; &rfc2818; &rfc4346; &rfc4120; Google Google Proceedings of the W3c Security and Usability Workshop; http://www.w3.org/2005/Security/usability-ws/papers/37-google/'

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; 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. See for another case where confidential information in a UI can be used to build trust.

Clarified introduction to distinguish what happens at the TLS layer and what at the HTTP layer. Discuss motivation of phishing more. 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. Add a purpose of this memo section. Whatever text ends up there after community discussion needs to be called out in the last call. 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. Update the threat model. Significant hopefully clarifying changes.

Updated discussion of TLS authentication to point out that it does meet the requirement of mutual authentication. Added pointer to HTTP TLS channel bindings work

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. Clarify attacks of interest to be consistent with the introduction. 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. Clarify that in the mutual authentication case I'm concerned about authentication of client to the server. Clean up bugs in security considerations