Re: [dix] Updated phishing requirements draft

On 7/6/06, Sam Hartman <hartmans-ietf@mit.edu> wrote:
> >>>>> "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.

True, of course, but hardly relevant. What if it isn't an
authentication credential?

> However I don't see the claim you are referring to in the introduction.

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

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

If you mean that the solution must allow this mode, then sure. If you
are saying it must require it, then I think that excludes a whole
bunch of potentially useful solutions, like tokens, for example.

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

Then you have stored them all on one machine, surely? In your case you
don't want that machine to be 'net accessible, but that's not
everyone's case. What I'm saying is that there are many services where
users are generally happy to access them from anywhere, and you want
to be able to support that without requiring them to do anything other
than carry stuff around in their head.

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

It seems to me that there's a fuzziness around what you mean by
"support passwords" and trying to nail it down in a requirements
document is going to constrain the solution space, as well as making
the requirements hard to read.

Perhaps the requirement should be that if passwords are used to
authenticate the user then they MUST be used in a way that does not
give service A a way to log in to service B, even if the user uses the
same password to access the same server.

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

I agree that it is likely to be the common case. The language should
not make it the only case. If you use "authentication credential"
instead of "password", then it fixes the problem, surely?

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

I agree - I think I may be wrong about this one. I'm still musing
about whether the word "cryptographically" is necessary in the text,
or whether simply stating that it is bound is the way to go.

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

OK, I see what you mean, but now I'm puzzled why you say
authentication of the client at the TLS layer is not sufficient? If I
use a client cert to authenticate, surely it doesn't matter whether I
authenticate to the correct server of a phisher - the phisher cannot
reuse my cert to access the real server.

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

Yes. Though I'd prefer it if we didn't insist that it was the HTTP
response that was decrypted.

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

I don't understand how 1 maintains privacy. In any case, it seems to
me that a requrement should be that solutions can preserve the user's
privacy, should the user wish to have it preserved.

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

You could define an identity provider (or some other term) as a third
party that participates in authentication.

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

If the attacker is someone other than the server, then all you need is
for the authentication to have been encrypted, surely?

>
> _______________________________________________
> dix mailing list
> dix@ietf.org
> https://www1.ietf.org/mailman/listinfo/dix
>

_______________________________________________
dix mailing list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix