NW-PP18 Web Authentication, TLS and phishing

[Lisa: feel free to re-post with a proper PP number.]

Abstract

   Cryptographic user and server authentication, and cryptographic
   transport protection are requirements for dealing with modern threat
   models for the Internet.

   Phish attacks aim to steal credentials, but if not credentials, then
   man-in-the-middle (MITM) access.

   It is important to ensure that user/service authentication and
   cryptographic transport protection are cryptographically bound so as
   to avoid MITM attacks.

   Implied, of course, if authentication stronger than the current
   reigning champion: username&password-over-TLS (which does not, and
   cannot support channel binding).

   Additionally, phishing opportunities must be limited, such as by
   using authentication tokens that cannot be captured and played to
   other relying parties.  One goal is to push phishing opportunities to
   the edge of the system: enrolment.

   "Nigeria scam" type phishing is out of scope for this paper, but
   phishing attacks where a user is directed to a malicious site (e.g.,
   via spam e-mail) or where the user accidentally goes to a malicious
   site (e.g., via typo-squatting) are in scope.

Introduction

   Current practice for web authentication follows this pattern:

    - The client is directed (or re-directed) to an https URL using...
    - ...TLS with server certificate and anonymous client
    - The page at the https URL contains an HTML form with username and
      password text input fields; the form is [usually] POSTed via an
      https URL
    - When the browser posts said form the server sets a protected [and,
      where encryption is not required, an unprotected] cookie
    - Subsequent HTTP requests include said cookie, which contains or
      points to server-side state indicating who the user is and that
      they are authenticated

   Web applications generally involve many HTTP requests, using HTTP as
   a sort of reliable datagram transport.  Usually multiple TCP
   connections are used, with little multiplexing of HTTP requests
   per-TCP connection.

   A few observations:

    - Username-and-password-over-TLS authentication is not very strong
       - Stealing usernames and passwords is a common phish attack goal,
	 as those provide the access that attackers desire (e.g., to
	 one's bank accounts)

    - Server certificates are only as good as the CAs that issue them
       - There are a multitude of CAs, and browsers ship with large
	 trust anchor sets
       - There is no true global PKI
       - Server certificates are easy to obtain for typo and confusable
	 versions of legitimate domain names
          - It is easy to obtain typo and confusable versions of
	    legitimate domain names; DNSSEC will not change this

    - That said, cookies are a fine mechanism for associating a
      multitude of HTTP requests with a given application session
       - The use of cookies reduces the need for potentially expensive
	 authentication events
       - If one think of a reliable datagram transport with built-in key
	 exchange, authentication and encryption, then one can see that
	 a protected cookie is a perfectly reasonable method of
	 associating datagrams with sessions, thus reducing the number
	 of authentication events needed per-session (there is plenty of
	 precedent for this too)

    - So we need: better authentication of users and, possibly, servers
       - And we need to make sure that this authentication is strongly
	 bound to the transport-layer encryption (TLS, in this case)
	  - Server authentication is already so bound

       - Cryptographic binding of user and server authentication, and,
	 direct or indirect cryptographic binding of authentication to
	 key exchange and session cryptographic protection is required
	 to detect MITMs

   I've been told several times that web authentication should happen at
   the application layer.  Often the rationale is that developers don't
   like browsers' HTTP authentication dialogs, that they prefer to use
   HTML forms so that they can have more control over the authentication
   UI.

   At the same time every one seems to agree that sending username and
   password over TLS is a big part of the phishing problem, that we need
   better authentication methods.

   Arguments for why user authentication belongs in the application
   layer, even when using something other than plain username&password,
   can also be made.  For example:

    o Authentication at the application layer allows application control
      over when it occurs, and application control over such UI elements
      as are reasonable to put in the hands of the application

    o Faster prototyping and more competition are possible if user
      authentication takes place at the application layer; otherwise the
      transport, browser and server stacks need to be re-deployed for
      authentication mechanism that anyone invents.

      On the other hand, one might argue that the difficulty of
      deploying new authentication mechanisms is a defense against bad
      authentication mechanisms, and that this is a good thing.

Channel Binding

   The rest of this document assumes reader familiarity with the concept
   of channel binding [RFC5056].

   Briefly, channel binding is a concept, dating to the early 1990s,
   where authentication at one layer is cryptographically bound to a
   secure channel (e.g., a TLS session, or a set of TLS sessions), such
   that no man-in-the-middle may exist when authentication with channel
   binding succeeds.  Channel binding functions just like the binding
   between authentication and key exchange that protocols like IKE, TLS
   and SSHv2 already do, but with authentication removed to a higher
   network layer, usually the application layer.

Internet and Phishing Threat Model

   Prior to the advent of phishing we have worried against a variety of
   active and passive attacks on Internet protocols, particularly active
   off-path attackers.  But the rise of open wireless networks and the
   rise of phishing mean that we must take passive attacks (e.g.,
   eavesdropping) and active attacks (e.g., server impersonation, MITM
   attacks) more seriously.

   A modern threat model for web applications should include:

    - passive attackers (e.g., eavesdroppers on open wireless networks)
    - active off-path attackers (e.g., sender spoofing)
    - active on-path attackers (e.g., MITMs)
    - active mis-direction attacks (phish attacks)
       - keeping in mind that phishers are after resources protected by
	 the user credentials that they usually try to steal

Federation

   Until recently users needed a username and password for every site
   and/or application that they used.  This multiplicity of passwords is
   difficult to manage, and quite frustrating to users.  Thus, users
   often use the same username and password across many unrelated sites,
   which makes theft of their credentials all the more dangerous to the
   users.

   Merely replacing usernames and passwords with stronger authentication
   methods may not reduce the number of identities that users must
   manage, but it does present the opportunity to do so.

   Assuming stronger authentication methods, one way to reduce the
   number of identities per-user is to allow one identity and/or related
   authentication infrastructure to be used for many sites.  Credential
   theft in such a model is mitigated by making it difficult for
   attackers [who we assume do not have local access to the client] to
   steal the credentials; theft of authentication tokens should not be
   sufficient for impersonating the user.

   Implied in this is trust transitivity.  Identity federation supposes
   islands of trust (as opposed to a global PKI, or other authentication
   infrastructure).  Trust is no inherently transitive, and breaks down
   when trusted partners turn out to not be trustworthy, or as the trust
   chains become too long (does one trust a story related by a friend
   who heard it from a cousin who heard it from a friend who...?).

   Transitive trust can be implemented badly.  For example, if "bearer
   token," asserting that the possessor is authenticated as some
   identity, can be presented to any relying party that participates in
   the associated identity federation, then theft of such a token can
   lead to impersonation of the user.

   On the other hand, small islands of trust present the opportunity for
   white and black listing by the identity providers, which can be used
   to help protect users from illegitimate sites.

Rapid Prototyping of Web Authentication

   Various extensions to the JavaScript host environment on browsers
   could greatly facilitate the development and deployment of
   application-layer authentication for web applications.

   For example:

    - JavaScript bindings for existing authentication frameworks, such
      as SASL and the GSS-API (see UI note below)

    - JavaScript bindings for PKCS#11 and CMS/XMLdsig/XMLenc (see UI
      note below)

    - SAML APIs and JavaScript bindings for them (see UI note below)

    - extensions to the XmlHttpRequest object to allow applications to
      obtain the channel binding data for the request's TLS session

   Consider, with JavaScript bindings for PKCS#11.  Developers could use
   low-level cryptographic primitives to implement PKI and ad-hoc public
   key user authentication.

   Frameworks like SASL and the GSS-API are probably more appropriate
   (as the GSS-API does, or SASL soon will, support channel binding
   already).

   Of course, application access to authentication credentials through
   such scripting interfaces MUST be suitably limited.  For example, the
   application MUST NOT be able to use such interfaces to generate
   authentication messages suitable for impersonating the user to other
   services.  This can be done, in the case of SASL and GSS-API
   interfaces, by not allowing the application to control the name of
   the target service.  Additionally, user control, over what
   credentials a given application can access through such interfaces,
   MUST be provided (for example, a one-time dialog where the user can
   select an identity/credential to authenticate to a service as).

   In the case of a PKCS#11 interface, it is important to understand
   that not much control can be provided over what the application
   encrypts or signs, but control can be provided over what keys it can
   access.  A PKCS#11 interface would probably put too much power in the
   hands of the application, for the risk is probably great that keys
   may be made available through it which are sensitive and which the
   user does not understand that how to limit.  However, a PKCS#11
   interface would allow for rapid prototyping.

Enrolment

   Interfaces for adding identities and raw credentials for use with
   JavaScript interfaces to SASL, the GSS-API and/or SAML would be very,
   very useful.

   Ideally cryptographic user authentication methods, channel binding
   and small trust islands (as small as one per-{user, service}) will
   allow us to significantly reduce the possibility of phishing attacks
   at all but the time when the user enrols their identity/credentials
   with an identity provider and/or service.

   We may not be able to exclude phishing attacks on enrolment, but
   because enrolment is a rare event the opportunities for phishing
   would still be greatly reduced, to the point where education may be
   sufficient to make phishing very rare.

UIs, User Expectations and User Education

   Even with significant improvements in web authentication it will
   still be possible for phish attacks to succeed where users don't or
   can't know about how a web page is protected.  Experience tells us,
   too, that users do not look at, nor know what to do with, server
   certificates.  We need UI elements that are simple and comprehensible
   by most users, and which nonetheless convey critical security
   information.

   Perhaps the simplest piece of information that can be shown to the
   user, and which conveys the most important information, is the
   identity that was used to authenticate to a given service.  This
   assertion is predicated on having channel binding and either ad-hoc
   per-{user, service} credentials or sufficiently small trust islands
   (federations), for between the name of a service and the user's
   identity, the user has enough information to decide whether the
   session is legitimate.

   Of course, if a user can be tricked into enrolling to a malicious
   site such that: a) the site's name is similar to that of legitimate
   sites, and b) the user's identity is similar to that which would be
   used at legitimate sites, then the user can fail to realize when they
   are being phished.

   In the end phishing attacks are an on-line con-game.  As with
   con-games in the off-line world, human gullibility is the key, and no
   technology can completely make up for human gullibility.  By
   deploying better web authentication we may be able to greatly reduce
   phishing opportunities, but most likely we cannot prevent phishing
   altogether.  A web authentication scheme that requires phishers to
   attack enrolment limits the opportunity for phishing to the point
   where user education may have a chance.

Authentication Technologies

   A number of authentication methods are possible that can support
   channel binding:

    - methods based on PK crypto (e.g., user certs, bare user public
      keys, ala SSH)

    - methods based on pre-shared symmetric keys

    - methods based on passwords (e.g., challenge/response methods like
      DIGEST-MD5)

    - methods based on trusted key distribution (e.g., Kerberos V)

    - combinations of the above

   Radia Perlman and Charlie Kaufman have written a paper on
   "User-centric PKI" which recommends the use of bare public keys to
   identify users and the corresponding private keys to authenticate
   them -- this is very similar to SSH publickey authentication.  Using
   certificates (which they also recommend as a supported mechanism)
   allows for identity federation, effectively.  Passwords, of course,
   are the only truly portable authentication credential, at least until
   smartcards and smartcard readers are ubiquitous.  So protocols like
   SACRED are recommended as a method of accessing private keys when
   local tokens are not available.

Privacy Protection Considerations and Channel Binding

   Letting identity providers (IdPs) know what service the user wants to
   authenticate to allows the IdPs to perform white/blacklisting, and it
   allows user authentication to be bound to the service name at the IdP
   -- a useful property, in that it indirectly ensures channel binding.
   However, it also allows IdPs to know what services the user is
   accessing (and when).

   User authentication methods that involve an IdP but which do not
   involve sharing the names of the users' peers with the IdP are
   clearly feasible, but it is crucial, in such cases, to get channel
   binding right in the application protocol (or TLS, if user
   authentication is being done in TLS).

Recommendations for Web Authentication

   o Whether the future of web authentication entails application-layer
     user authentication, or whether user authentication actually moves
     into the TLS layer, the ability to detect MITM attacks is REQUIRED.

     For example, sending a "bearer token" which can be presented to
     many different relying parties is dangerous: there is no binding to
     a particular session, therefore theft of such a token can enable
     the thief to impersonate the authenticated user to other sites/
     applications.  All the thief needs to do is fool the user into
     sending it the bearer token and then the thief can impersonate the
     user to any site that would accept that token.

   o Authentication messages MUST NOT be replay-able in other sessions
     (see above) to other services.

   o Use of plain username-and-password-over-TLS is NOT RECOMMENDED;
     in fact, since it does not meet the above requirements, it MUST NOT
     be used.  Use of plain username-and-password-over-TLS to obtain
     other forms of credentials, however, MAY be used.

   o If user authentication moves to the transport layer (e.g., TLS),
     and if its computational and/or bandwidth cost be significant, then
     a method SHOULD be provided for a) controlling when TLS user
     authentication is used, b) binding occasional user authentication
     to a multiplicity of TLS sessions.

   o Browser UIs MUST display the user's identity, used to authenticate
     to a given site, as prominently as the name of the site and its
     URL, whenever the authentication method used is: a) cryptographic
     (not plain username&password), b) bound to the TLS sessions that
     make up the application session.

   [This section is left unfinished due to lack of time.  RFC2119-like
   terminology is used.]