[dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements
Eric Rescorla <ekr@networkresonance.com> Mon, 22 May 2006 15:58 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCnq-0005sZ-Mw; Mon, 22 May 2006 11:58:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCnp-0005sU-8P for dix@ietf.org; Mon, 22 May 2006 11:58:41 -0400
Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiCnk-0007ZS-IK for dix@ietf.org; Mon, 22 May 2006 11:58:41 -0400
Received: by raman.networkresonance.com (Postfix, from userid 1001) id 1D2741E8C1C; Mon, 22 May 2006 08:58:23 -0700 (PDT)
To: Sam Hartman <hartmans-ietf@mit.edu>
References: <tslr72mp213.fsf@cz.mit.edu>
From: Eric Rescorla <ekr@networkresonance.com>
Date: Mon, 22 May 2006 08:58:23 -0700
In-Reply-To: <tslr72mp213.fsf@cz.mit.edu> (Sam Hartman's message of "Mon, 22 May 2006 10:28:08 -0400")
Message-ID: <868xou831c.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8
Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org
Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements
X-BeenThere: dix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.com>, 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
1. This is not principally a protocol problem but rather a UI problem. The protocol problems are generally well understood. If the UI problems are solved, nearly any protocol will work. In particular, there have been a number of published designs [1] [2] that have mostly adequate (though not perfect) protocols, though without complete solutions to the UI problem. Indeed, a slightly different design for Digest (in which the absolute URI was hashed) combined with a secure UI would pretty much defeat current phishing attacks. 2. It's really important to distinguish between different levels of attack. Conventional phishing attacks rely on generating a reference which appears to be valid but actually points at the attacker's site. (This is why SSL/TLS doesn't help much). But this is different from attacks in which the attacker actually intercepts the user's communication. In these settings, some sort of cryptographic protection for the channel (a la HTTPS) or the messages (a la S-HTTP) must be provided. On a similar note, in current phishing attacks the attacker attempts to directly extract the user's password. If C-R mechanisms are used, a dictionary attack is natural. I assume that's why you wave in the direction of ZKPPs in S 4.3. However, it's worth asking whether we would be satisified with a system that was only partly strengthened against dictionary attacks (see [2] again). 3. The term "password equivalent" is a bit confusing. See draft-iab-auth-mech for some discussion of strong versus weak password equivalent. 4. I agree that server authentication is a good, but I'm not totally sold that it's a necessity. It's principally important when you're changing credentials, but even then with a properly designed scheme where the server has a weakly password equivalent credential, the exposure is fairly limited. A standard practice is to hash the hostname into the password hash stored on the server. 5. You write: 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. This is not strictly true. A ZKPP removes the risk of offline dictionary attack, but not online attack. These attacks do still get mounted [3] 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. It's not clear to me that this helps, unless you're assuming a ZKPP. If the attacker can capture a hashed password or C-R handshake (which a phisher can generally force in non-ZKPP cases) then they can mount an offline dictionary attack anyway. Consider a typical design where the user has a master password P and then generates per-site passwords as H(Site-Name || P). In the C-R handshake, the user provides: H(challenge || H(Site-Name || P). Dictionary attacking this isn't significantly harder than dictionary attacking H(Site-Name || P). 6. You write: 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. I agree that this is is a likely business goal for identity providers, but it's not required for protection against phishing. Really, there are two interests here: 1. To prove to the user (the guy with the browser) that he is doing business with an "authorized" provider. 2. To allow the identity provider to extract rents from the relying parties. Neither strictly requires the relying party authenticating to the identity provider during the transaction. The first can obviously done by issueing the relying party a long-term credential. The second can be done by encrypting the credential under the relying party's key. You don't necessarily need the identity provider to receive a proof that the relying party was able to decrypt it. -Ekr [1] Blake Ross, Collin Jackson, Nicholas Miyake, Dan Boneh and John C. Mitchell Stronger Password Authentication Using Browser Extensions. Proceedings of the 14th Usenix Security Symposium, 2005. [2] Halderman, J. A., Waters, B., and Felten, E. W. 2005. A convenient method for securely managing passwords. In Proceedings of the 14th international Conference on World Wide Web (Chiba, Japan, May 10 - 14, 2005). WWW '05. ACM Press, New York, NY, 471-479. DOI= http://doi.acm.org/10.1145/1060745.1060815 [3] http://www.whitedust.net/article/27/Recent%20SSH%20Brute-Force%20Attacks/ _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix
- [dix] Re: [Ietf-http-auth] New draft on anti-phis… Eric Rescorla
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Nicolas Williams
- [dix] Re: [Ietf-http-auth] New draft on anti-phis… Nicolas Williams
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Eric Rescorla
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Eric Rescorla
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Nicolas Williams
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Eric Rescorla
- [dix] New draft on anti-phishing requirements Sam Hartman
- [dix] Re: [Ietf-http-auth] New draft on anti-phis… Robert Sayre
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Sam Hartman
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Sam Hartman
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Sam Hartman
- [dix] Re: [Ietf-http-auth] New draft on anti-phis… Sam Hartman
- [dix] Re: [Ietf-http-auth] New draft on anti-phis… Sam Hartman
- [dix] Re: [Ietf-http-auth] New draft on anti-phis… Eric Rescorla
- [dix] Re: [Ietf-http-auth] New draft on anti-phis… Eric Rescorla
- [dix] Re: [Ietf-http-auth] New draft on anti-phis… Nicolas Williams
- [dix] Re: [Ietf-http-auth] New draft on anti-phis… Robert Sayre
- [dix] Re: [Ietf-http-auth] New draft on anti-phis… Sam Hartman
- [dix] Re: [Ietf-http-auth] New draft on anti-phis… Nicolas Williams
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Thomas Roessler
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Chris Drake
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Eric Rescorla
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Nicolas Williams
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Eric Rescorla
- Re[2]: [dix] Re: [Ietf-http-auth] New draft on an… Chris Drake
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Eric Rescorla
- Re: [dix] Re: [Ietf-http-auth] New draft on anti-… Eliot Lear