Usable Access Control for the World Wide Web
Dirk Balfanz
Palo Alto Research Center


Synopsis:
This paper was presented at the Annual Computer Security Applications
Conference. It is a concept paper, and focuses on a security concept from
a usability point of view. Instead of looking at complex access control
lists like other papers, this one focuses on implementing security through
simplicity.

The problem with publishing content on the WWW is that it is too hard to
manage permissions for regular uses. For example, John Doe might want to
share his family vacation pictures with his friends and extended family,
but not with the rest of the world. He is stuck with two options: security
through obscurity or simple password protection schemes.

Security issues are oblivious to a non-technical user. Popular programs
like Microsoft's Internet Explorer make no efforts to enhance security.
For example, IE will ask the user for their decision when a web page tries
to launch a "file or program in IFRAME." The paper goes on to discuss
limitations of current solutions provided by state of the art web servers
like Apache, Tomcat and IIS. The user has to be somewhat technically
inclined to use them in the first place. Even user-friendly software
packages like .MAC and Frontpage have their limitations.

The author of this paper implements the idea of a simple to use ACL on the
WWW, by implementing ESCAPE: Easy and secure content authorization and
publishing engine. There are severe limitations to this implementation as
it is only a proof of concept. However, the basic idea behind the software
is that users create-publish-announce. During the announce phase, we can
deduct the intentions of the publisher. For example, if the user sends
e-mail to 10 other people, we know the intention is to open up content to
those 10 people. The ESCAPE system interfaces with the user's Outlook
address book to keep track of the ACLs. ESCAPE creates a special URL for
all those 10 people by appending their e-mail address to keep track of
unique users.

Content is server over SSL. When a user first accesses the content, they
have to through a one-time process of acquiring a SSL certificate (which
is quite user-unfriendly if you ask mebut more on that later). The
certificate is saved on the server and the public key for this certificate
is stored in the publisher's address book. Once the certificate has been
established to the client, the user does not need to go through the
one-time process of acquiring the certificate. ESCAPE saves the public key
for the certificate in the user's OUTLOOK address book instead of
somewhere else on the server because for two reasons: the publisher can
revoke access at any time and if a wrong person has acquired a
certificate.

In a nutshell, ESCAPE authenticates visitors by assigning a unique URL in
the initial e-mail announcement sent out by the publisher. The visitor is
required to accept an SSL certificate to view the content. This is all
done without the publisher or the consumer ever having to set, type or
utilize or login or password. Everything is done pretty much transparently
and without the user's input.

Pros:
+ Ease of use
+ Allows small publishers to protect content
+ Producer does the work, not the consumer
+ Proof of concept implementation (not just theoretic)
+ Attacking the right problem
+ Merge Authentication with OS feature
+ Used existing systems and resources
+ Thorough analysis

Cons:
- Doesn't define usable
- No user tests
- Based on own notion of "nave user"
- System restrictions/limitations
- Not the most secure system

Discussion Questions:

[1] One big loophole: forwarding e-mails from a consumer to a non-invited
consumer. On leaking content, the paper claims that: "authorized users can
always download content they have access to, destroy watermarks embedded
in it, and then forward it to unauthorized users." I feel that the author
is losing track of the objective here. I feel it is safe to assume that
most non-technical users won't have the know how to watermark their
content and their primary object isn't to safeguard content for copyright
issues as much as for privacy. Even then, what steps can be taken to stop
content leakage? If another certificate is required (for whatever reasons
- another computer, browser or lost certificate): an e-mail with a new
link should be sent directly to the consumer.

[2] User ease of use: Is it really that easy to use? What do you
think/feel? Aren't there are too many nagging security screens? What would
the user feel about accepting certificates?

[3] E-mail invites seem too simple and easy to guess. Wouldn't an
inquiring mind guess URLs based on few e-mails of know friends and friends
of friends to successfully acquire content?

[4] Related question: what if an attacker gets the certificate before the
intended consumer? Easily revoked, but a hassle.

[5] Sharing of keys: a technically inclined consumer may decide to share
keys with another user. However, they can just as easily share the content
after downloading it. But sharing the keys give them unlimited access to
future publications (if the original user has access)

[6] Multiple access points: There is no way in ESCAPE to let multiple
computers of a user access the content without renegotiating the
certificate each time.

[7] What about key importing/exporting with an ease of use. Any ideas?

[8] Certificate delivery: Man in the middle attack. However, the window of
opportunity is very small. It seems reasonable given the ease of use. Any
methods to improve the way this is implemented without using SSL?

[9] A bigger philosophical question: Can true security be done in a
seamless manner? With complete ease of use? Transparent to the
non-technical user?

[10] Can seamless security scale to large audiences, how would one modify
the system?

[11] Can security through ease be cross-platform? Is it severely limited
to homogenous systems?

[12] Certificate delivery through other medium? More secure? But more ease
of use?

Summary Votes:
* Strong Accept: 0
* Accept: 6
* Reject: 3
* Strong Reject: 0