Re: [dix] Updated phishing requirements draft
Sam Hartman <hartmans-ietf@mit.edu> Thu, 06 July 2006 21:11 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyb8P-0004wU-TT; Thu, 06 Jul 2006 17:11:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyb8O-0004lf-GS for dix@ietf.org; Thu, 06 Jul 2006 17:11:40 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyaOF-0007We-4b for dix@ietf.org; Thu, 06 Jul 2006 16:23:59 -0400
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyaNr-0003lG-JL for dix@ietf.org; Thu, 06 Jul 2006 16:23:39 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B0A8CE007A; Thu, 6 Jul 2006 16:23:55 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Digital Identity Exchange <dix@ietf.org>
Subject: Re: [dix] Updated phishing requirements draft
References: <tslac7x6x98.fsf@cz.mit.edu> <1b587cab0607030622s1c9dbad5v5a0ede75454f09e@mail.google.com>
Date: Thu, 06 Jul 2006 16:23:55 -0400
In-Reply-To: <1b587cab0607030622s1c9dbad5v5a0ede75454f09e@mail.google.com> (Ben Laurie's message of "Mon, 3 Jul 2006 14:22:07 +0100")
Message-ID: <tsl64iaa3dw.fsf@cz.mit.edu>
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: -2.5 (--)
X-Scan-Signature: b7b1e91f6d312d4248b994050b22d659
X-BeenThere: dix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Digital Identity Exchange <dix@ietf.org>
List-Id: Digital Identity Exchange <dix.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dix>
List-Post: <mailto:dix@ietf.org>
List-Help: <mailto:dix-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=subscribe>
Errors-To: dix-bounces@ietf.org
>>>>> "Ben" == Ben Laurie <benl@google.com> writes: Thanks for your comments. I hope that we can work together to address them. >> >> Hi. I submitted a 01 version of my phishing requirements draft >> Sunday evening, but it has not yet popped out the other side so >> I'm including it below. >> >> I've tried to improve it based on review comments. I did not >> get a chance to address everything; I was focusing on some >> obvious issues of clarity and on refining my thoughts so that >> the draft reflects my current understanding of the area. I do >> thank all those who sent comments both on the list and >> privately. I also thank those who were willing to walk through >> the requirements with me and help me confirm that the >> requirements are sufficient for what I'm trying to achieve. >> >> >> >> >> >> >> Network Working Group S. Hartman Internet-Draft MIT Expires: >> December 27, 2006 June 25, 2006 >> >> >> Requirements for Web Authentication Resistant to Phishing >> draft-hartman-webauth-phishing-01.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 December 27, 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 December 27, 2006 [Page 1] >> >> Internet-Draft Web Phishing Requirements June 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. >> Mutual Authentication . . . . . . . . . . . . . . . . . . 9 >> 4.5. Authentication Tied to Resulting Page >> . . . . . . . . . . 10 4.6. Restricted Identity Providers >> . . . . . . . . . . . . . . 11 4.7. Protecting Enrollment >> . . . . . . . . . . . . . . . . . . 11 5. Is it the right >> Server? . . . . . . . . . . . . . . . . . . . 13 6. Security >> Considerations . . . . . . . . . . . . . . . . . . . 14 7. >> References >> . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. >> Normative References . . . . . . . . . . . . . . . . . . . 16 >> 7.2. Informative References >> . . . . . . . . . . . . . . . . . . 16 Author's Address >> . . . . . . . . . . . . . . . . . . . . . . . . . 17 >> Intellectual Property and Copyright Statements >> . . . . . . . . . . 18 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hartman Expires December 27, 2006 [Page 2] >> >> Internet-Draft Web Phishing Requirements June 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 December 27, 2006 [Page 3] >> >> Internet-Draft Web Phishing Requirements June 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 December 27, 2006 [Page 4] >> >> Internet-Draft Web Phishing Requirements June 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 December 27, 2006 [Page 5] >> >> Internet-Draft Web Phishing Requirements June 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 December 27, 2006 [Page 6] >> >> Internet-Draft Web Phishing Requirements June 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. Ben> This contradicts the introduction, which says you are only Ben> interested in authentication credentials. First, that's not true if the information in question is an authentication credential. However I don't see the claim you are referring to in the introduction. >> 4.1. Support for Passwords >> >> The web authentication solution MUST support passwords and MUST >> be secure even when passwords are commonly used. Ben> It seems to me you are presupposing the solution to your real Ben> requirement, which is that the user must be able to walk up Ben> to any machine and use it to log in. It is not obvious to me Ben> that this means it must support passwords (at least not to Ben> more than one site, say the one where I've stored all my Ben> credentials). I think that supporting passwords between you and your IDP and supporting other credentials between your IDP and websites meets this requirement. I believe the real requirement here is that the protocol must support me walking up to a machine, choose an identity and type in apassword for that identity. I completely disbelieve that users will store their identities/credentials on one machine. There's no way MIT would let me store long-term work credentials on a machine I control in a form that could be accessed over the net. There's no way I'd store my long-term personal credentials on a machine MIT controls. Neither of us are interested in third parties. Thus, I suspect there's no one machine besides the client I'm in front of now that can get access to my credentials. However I think we're talking about something similar. I'd definitely consider text to better describe the requirement provided that it did not make it less readable to non-security folk. >> 4.3. No Password Equivelents >> >> A critical requirement is that when a user authenticates to a >> website, the website MUST NOT receive a strong password >> equivalent [IABAUTH]. A strong password equivalent is anything >> that would allow a phisher to authenticate as a user with a >> different identity provider. Weak password equivalents 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. Ben> Again, you are presupposing the necessity of Ben> passwords. Surely this should be "no authentication Ben> credential equivalents". I'm quite certain that passwords will be the common case. You're correct that the requirement is that credentials are not sent. I think the text of the requirement makes that clear; if not I'd appreciate revisions. I believe the title is more readable to non-security audiences than your proposed title. >> 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. Ben> Once more you are presupposing the solution. One-time Ben> passwords work find for this purpose but are not Ben> (necessarily) cryptographically bound to anything. I don't see how one-time passwords that are not bound to a particular recipient meet the requirement. If I have a one time password and am trying to authenticate to Bob, but accidentally give the password to BOb, I don't want BOb to be able to take the (as-yet unused) one-time password and give it to Bob. I'm also sort of confused about how you have a one time password that is not cryptographically bound to a specific relying party. Typically that relying party is some backend authentication server but that still meets this requirement. >> 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 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. So an authentication solution for >> phishing MUST detect the situation where the server ignores or >> does not participate in the authentication. Ben> This doesn't follow - the situation you have described is one Ben> where the server _does_ participate in authentication. The Ben> problem is that they are not the server the user thinks they Ben> are,. The server participates in the TLS authentication but does not participate in other authentication layers. For example on todays web, the server accepts but does not verify a password filled into an HTML form. Again, rewording is appreciated. >> >> The authentication system MUST guarantee to the user and the >> target server that the response is generated by the target >> server and will only be seen by parties authorized by either >> the target server or the user. Ben> The requirement, surely, is that the response is not _useful_ Ben> to eavesdroppers, rather than not seen. There are plenty of Ben> protcols that can be run totally in the clear that leave Ben> nothing useful for an observer (e.g. Diffie-Hellman key Ben> agreement). Would it help to clarify that I mean the decrypted contents of the HTTP response? >> 1. The target server can provide a certificate issued by the >> identity provider as part of the authentication. >> >> 2. The identity provider can explicitly approve the identity. >> 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. Ben> A general criticism, but particularly apropos in this Ben> section: you appear to have no concern for the privacy of the Ben> user. It should be possible to authenticate without revealing Ben> to the identity provider who you are authenticating to. You're correct that I personally care very little about that form of privacy. However you'll note that I explicitly mention an option allowing you to meet this requirement while maintaining privacy. See 1 above. Ben> Incidentally, you've suddenly started talking about identity Ben> providers without saying what they are. Yes. I'm not entirely sure how to fix that without making the draft less general. Suggestions welcome. >> 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. Ben> This just isn't true. An attacker can always assume the role Ben> of the client and try to authenticate using their dictionary Ben> of passwords. This works no matter what the authentication Ben> mechanism is. If the attacker is the server then they can do Ben> this very efficiently (since they do not have to do it over Ben> the network). You are of course correct. What I meant to say is that the risk of offline dictionary attack can be removed for attackers other than the server if ZKPPs are used. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix
- [dix] Updated phishing requirements draft Sam Hartman
- Re: [dix] Updated phishing requirements draft Eliot Lear
- Re: [dix] Updated phishing requirements draft Sam Hartman
- Re: [dix] Updated phishing requirements draft Eliot Lear
- Re: [dix] Updated phishing requirements draft Sam Hartman
- [dix] Comprehensive list - known Threat and Prote… Chris Drake
- Re: [dix] Updated phishing requirements draft Ben Laurie
- Re: [dix] Updated phishing requirements draft Sam Hartman
- Re: [dix] Updated phishing requirements draft Ben Laurie