>>>>> "Ben" == Ben Laurie <[EMAIL PROTECTED]> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
