NW-PP18 Web Authentication, TLS and phishing
Nicolas Williams <Nicolas.Williams <at> sun.com>
2008-02-09 00:01:00 GMT
[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.]
Tom Petch
----- Original Message -----
From: "Lars Eggert" <lars.eggert <at> nokia.com>
To: "tom.petch" <cfinss <at> dial.pipex.com>
Cc: <discuss <at> ietf.org>
Sent: Friday, February 08, 2008 8:23 AM
Subject: Re: Test
> On 2008-2-7, at 20:35, ext tom.petch wrote:
> > In case you were wondering what I was on about, this mailing list is
> > now
> > discuss <at> ietf.org
>
> Well, it used to be discuss <at> apps.ietf.org, and I guess the non-
> secretariat apps server was retired?
>
> Lars
RSS Feed